-
Notifications
You must be signed in to change notification settings - Fork 242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: Add Autocompress Control #122
base: main
Are you sure you want to change the base?
Conversation
These options allow users better control of when the assembler should turn specific instructions into their smaller equivalents, without having to change the enabled architectures. Signed-off-by: Sam Elliott <[email protected]>
Do we really need another option, when there are already existing options and best practices?
|
I put more motivation in the LLVM message, for which I apologise, I was writing both messages at the same time. From that motivation: This will become more useful as the following things happen:
This document says the following about
Another problem with In short, yes I do think we need an option for controlling this feature. I'll note that the proposed LLVM implementation correctly works with |
How does this interact with linker relaxation, which can also convert certain uncompressed instructions into compressed equivalents? That is, is this intended to be purely for the assembler, or is it also intended to constrain the linker's relaxations, and if so, how? |
Thanks for bringing this up. I see two main choices:
I am tending towards thinking the second is clearer. This option can be explained as "ensure exactly the instructions I wrote are used", which I think means it has to disable relaxation, or else you might still end up with not exactly what you wrote in the final binary. By this explanation, the option might need to disable the Branch Pseudos as well (which replace a short conditional branch with a short (inverted) conditional branch and a longer jump). I've covered neither of these options in my prototype so far, but I can update it if we think this is a reasonable direction. |
Don't forget that it cuts the other way, too. The assembler will expand |
That's what I meant by "Branch Pseudos as well (which replace a short conditional branch with a short (inverted) conditional branch and a longer jump)." In discussion yesterday, it was noted there are other complex pseudos that can emit more than one instruction ( I intend to update the proposal wording in this direction next week. I didn't hear much dissent about the proposed direction (including the disabling of relaxation and long branch pseudo instructions) in yesterday's RISC-V toolchain SIG and LLVM meetings, but I realise this is still a new proposal. I wonder if a better name might be I welcome more feedback about this proposal. |
Off the top of my head, I don’t have a great naming suggestion, but I do think the name should encompass the fact that we’re disabling these branch relaxations, too. “Resize” is the first verb that comes to mind that subsumes “compress” and “expand”, but it’s not especially descriptive. |
I spent too long thinking about the name since last week. Right now, we have Here are some suggestions I'm happier with though, which flip the negative/positive versions:
I'm leaning towards |
What about |
The problem with |
This is not correct. As I said, I'm looking further ahead, to longer-than-32-bit instructions, which some custom extensions are already defining, as well as ensuring that we get exactly one 32-bit conditional branch rather than a conditional branch and a jump. I do sort-of agree with the layering of "no" and "auto" being fairly confusing, so want to get away from that. I'm going to proceed with I don't expect |
I still feel much better choices are I kind of like that unconfusing conjugal pair of verbs allow and deny. |
allow/deny is out of place with all the existing .option boolean toggles. fullsize/halfsize/allow16bitinst/deny16bitinst does not encompass the more-than-two instruction sizes that exist once you include 48-bit instructions, as this proposal is trying to do. (no)exact is the best name I've heard so far, in my opinion. |
These options allow users better control of when the assembler should turn specific instructions into their smaller equivalents, without having to change the enabled architectures.
A prototype LLVM implementation is available here: llvm/llvm-project#122483